perf(regex): identify a literal by its source site, not by its pattern text - #9892

Depends on #9891 (stacked; the diff shown here includes it until that lands).

Stacked on perf/regex-newborn-barrier-gate.

What

regex::site_cache answers "have I seen this pattern TEXT before?" — the
right question for a dynamic new RegExp(s), and the wrong one for a literal,
which is one source site whose pattern and flags are fixed at compile time.
Because a content fingerprint can collide, every hit is verified by a full
byte compare of the pattern (site_cache.rs:125,
&*entry.pattern == pattern). A literal evaluates to a fresh object every time
it is reached, and claude-code's segment loop constructs string-width's
~12,807-character /…/g once per grapheme: PERRY_REGEX_DIAG measured 2.0 GB
of memcmp per 400-character reply, and a sample put _platform_memcmp at
39.6 % of js_regexp_new's own subtree.

Expr::RegExp now emits an 8-byte private global per literal site
(@perry_regexp_site_<prefix>__<n>, private global i64 0) and passes its
address to a new js_regexp_new_site(pattern, flags, site_key).

Why an address and not an integer id

An integer id would have to be unique across separately compiled modules. An
address is unique by construction (distinct globals have distinct addresses),
immortal and never moves — the three properties a StringHeader address
lacks, which is exactly why the earlier analysis of this problem concluded no
sound string identity was available and left the byte compare in place: string
headers are GC-managed, so an address is freed and reused, and a moving
collector relocates them, and a pointer-keyed cache over them answers for a
different pattern.

A hit therefore verifies with one word plus the site's ≤ 8-byte raw flags
text — flags are compared because two spellings of one canonical form (/x/ig,
/x/gi) must not answer for each other — and then reads nothing about the
pattern: no fingerprint, no memcmp, no validation (validity is a pure function
of the pair and the site's first construction established it), no flag
canonicalization (the seven bits are a property of the site). Once the site's
first header has executed, later constructions are born built.

site_key = 0 means "no site": every dynamic construction
(js_regexp_construct, RegExp.prototype.compile, the runtime's own callers)
keeps the two-argument entry point and never touches the table.

Tests

• The named sabotage — key the table by pattern length. Two literals at two
  sites, same flags, same pattern length, different text, each constructed
  twice (a first construction always misses and would pass under every
  sabotage). Under a length- or prefix-keyed table the second site inherits the
  first's entry: .source reports a pattern the literal never contained and
  test matches the wrong language.
• A dynamic construction records nothing. Four js_regexp_new calls leave
  the table empty; one js_regexp_new_site call fills it — so the zero is a
  property of the entry point, not of a table that never works.
• A site hit after the first execution is born built — otherwise a hit that
  skipped the content cache would push the pattern's hash back onto the first
  test() and the site key would buy nothing.
• The declaration is asserted by name AND arity. A missing declare is
  invisible to every HIR-level test and fails only at the in-process LLVM parse
  (feat(codegen): match the Intl.Segmenter for-of and answer it from the runtime view mode (default OFF) #9859's five segment-view externs, after twelve passing unit tests); a wrong
  arity parses and miscompiles.

Kill switch

PERRY_REGEX_SITE_KEY=0 — the probe misses and nothing is recorded, so the OFF
arm is the content-keyed path exactly.

What the probe can and cannot show

The segment-loop probe cannot show this change. Its literal is ~60
characters, so its memcmp is 0.16 % of the thread. The evidence has to come
from the cc rig, where the 12,807-character pattern lives — a full bundle
compile with PERRY_REGEX_DIAG armed on one 3300-char reply.

Registered prediction, as a ratio because the two captures are different
runs with different diag windows and only same-run counts may be registered as
absolutes: site_verify_bytes / new collapses toward zero while
compiles std / fancy / repeat are unchanged. A compile count that moves
means the site table answered for a pattern it should not have.

Retention caveat, since this adds state

The site table is 1,024 entries. Holding their programs strongly cost
+20…+50 MB settled and idle CPU 2.37 → 2.68 s on cc — measured, not
assumed, and exactly the trade the directive rejects. Fixed before this PR
went up for review: the entry holds them Weak, so the table can hand
programs out but can never be why they stay alive. See the Results section
below for the three-arm comparison that establishes it. What the entry still
holds strongly is the (pattern, flags) text, which is small — but if a future
capture shows settled memory above main's, that text is the next thing to bound
(cc's emoji literal is 12,807 bytes and there are 1,024 slots).

A pre-existing hazard this work surfaced

Filed as #9890 and since fixed by #9896: codegen/method.rs's "parent class
has no callable constructor symbol" bail-out lowered the body and then discarded
ic_globals, typed_parse_rodata and pending_declares, so anything that body
declared was referenced by emitted IR and never defined. Pre-existing; the site
global this PR adds would have been one more victim. Every return there now goes
through publish_lowered_fn_artifacts, which drains all three and restores
llmod.ic_counter — closing the quieter half too (site ids reissued to the next
function, giving a duplicate-symbol redefinition). The comment at the lowering is
now written as the standing obligation rather than as a live bug.

Results on cc (perrymaster, quiet box)

Three arms: main5, I6 (main5 + this stack, programs held strongly) and
I6b (I6 + the weak-programs fix, 59cc2a3fb, 6,116 site globals in the
bundle). Raw: /root/armI6B_9838.log,
/root/rig9831/regexdiag_{I6b,I6,main5}_3300.txt, combI6B.jsonl.

CPU — 5×3300, paired

MIN −6.4 %, mean −5.4 %, 5 of 5 paired draws. 400-char: 0.96 → 0.96
(unchanged). Under contention MIN is the estimator; both are reported because
the arms are load-matched here (load 4.9 → 0.5).

Counters — one 3300-char reply, PERRY_REGEX_DIAG

The compile counts are identical across all three arms — the registered
falsifier, which a site table answering for the wrong pattern would break.

Memory — the cost, stated plainly

Peak RSS at 3300: 608–616 → 618–626 MB, +3…+15 MB (~2 %). That is the
price of this change and it is not hidden: the directive is both metrics
together, so a reviewer should weigh ~2 % peak against −5…−6 % CPU rather than
read the CPU line alone.

Settled at 120 s: main5 480/477 vs I6b 488/489 MB (+8…+12). Read that as
not resolved at n=2, not as a win: main5's own settled figure ranged
474–510 MB across today's runs, a spread of 36 MB, which is wider than the
delta. What the third arm does establish is the direction of the fix — I6, with
the site table holding its programs strongly, settled at 500/527 (+20…+50)
and idle CPU 2.37 → 2.68 s. Holding them weakly removes most of that, which
confirms the strong program references were the retention rather than leaving
it to be argued.

400-char settled: 459/461 → 467/462.

Landing order and state

#9891 → #9892. This PR is stacked on the newborn-barrier gate; its diff
includes that PR until it lands.

Rebased onto 504e180d0. The only file main touched that this branch also
touches is runtime_decls/strings.rs, and the overlap is purely additive at a
different site (2a71d706e declared the five js_segments_view_* externs at
line 1584; this adds js_regexp_new_site at 1321). Neither side changed a type
or a contract the other depends on.

The rebase also rewrites one comment: the note at the Expr::RegExp lowering
described codegen/method.rs's artifact-discarding bail-out in the present
tense, and #9896 fixed it (every return there now goes through
publish_lowered_fn_artifacts, which drains all three collections and restores
llmod.ic_counter, closing the duplicate site-id half too). It is now written
as the standing obligation — every lowering exit must publish
typed_parse_rodata — because a comment describing a hazard that no longer
exists is the false lead it was written to prevent.

Green before the rebase (e76026209): runtime lib 3,246 passed / 0 failed /
4 ignored (exactly +2 against the previous SHA's 3,244 — the two
weak-programs tests), perry-codegen RC=0, gate-equivalent clippy rc=0 with no
warning naming any file this stack touches. The rebased tree is type-checked
(cargo check --release --all-targets, lib and tests, rc=0 for both perry-runtime and perry-codegen, with no warning naming a file this stack touches); the dev box is at 8 GB free,
below the campaign's 12 GB build floor, so the full suite has not been re-run on
the rebased SHA and CI is the compile gate for it.

The changelog fragment's numeric prefix is 9886, not this PR's number, and
#9891's is 9885. The gate hard-fails only on a missing prefix and warns on
a wrong one deliberately — scripts/check_changeset_fragment.sh says a strict
rule would block backfills and stacked PRs, which is exactly this pair.
Renumbering would mean rewriting both commits again immediately before landing,
for a warning the gate is designed to emit.

Summary by CodeRabbit

• Performance

  • Improved regular expression literal construction by reusing validated pattern data and compiled programs for repeated executions.
  • Reduced unnecessary garbage-collection barrier work for newly created regular expressions while preserving safety when required.

• Compatibility

  • Dynamic regular expression construction continues to use its existing behavior.
  • Regular expression literals from different source locations remain isolated, even when their text is similar.

• Diagnostics

  • Improved diagnostic reporting, including more reliable output and earlier initial snapshots.